Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minor patches to TBB Windows build for compatibility with RTools make #2999

Merged
merged 9 commits into from
Jan 31, 2024

Conversation

andrjohns
Copy link
Collaborator

Summary

This PR applies some minor changes to the TBB's build rules on Windows so that it can be compiled with the version of make bundled with RTools - users will no longer need to additionally install mingw32-make on windows.

These changes are based on RcppParallel's changes.

I've run a GHA workflow which shows that the Math library & TBB successfully build with these changes under RTools40, RTools42, and RTools43 - without needing to install any additional packages

Tests

N/A - existing tests should still pass, testing workflow already run to confirm successful build

Side Effects

N/A

Release notes

Updated TBB Windows build rules for compatibility with RTools make

Checklist

  • Copyright holder: Andrew Johnson

    The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
    - Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
    - Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

  • the basic tests are passing

    • unit tests pass (to run, use: ./runTests.py test/unit)
    • header checks pass, (make test-headers)
    • dependencies checks pass, (make test-math-dependencies)
    • docs build, (make doxygen)
    • code passes the built in C++ standards checks (make cpplint)
  • the code is written in idiomatic C++ and changes are documented in the doxygen

  • the new changes are tested

@andrjohns
Copy link
Collaborator Author

I've also left the existing usage of mingw32-make in the header tests workflow, to show that the changes won't break any existing configuration

@andrjohns
Copy link
Collaborator Author

@WardBrian Any chance we could sneak this through in the 2.34 release? It would help simplify the windows setup steps (only need to set PATH now)

@wds15 would you happen to remember the POSIX issues that led to the mingw32-make requirement? I haven't experienced any build or runtime issues yet, but want to double-check that I'm not missing anything

@andrjohns
Copy link
Collaborator Author

andrjohns commented Jan 10, 2024

Could we do this in the code that calls the TBB makefiles, rather than needing to modify them here? (I don't mind the extra /s later on)

If so, could we provide some alternative variable like WINDOWS_HAS_SH or something?

@WardBrian good call! I've updated the makefiles to first do a check for the presence of sh, which can be overridden by manually setting WINDOWS_HAS_SH

@WardBrian
Copy link
Member

Changes look good now, thanks!

As for this in the 2.34 release, I'm torn. Calling the fact that make didn't work before a bug would allow it, but I also would not mind more time for testing on something like this.

@rok-cesnovar thoughts?

@rok-cesnovar
Copy link
Member

First of all, this is awesome. Not requiring mingw32-make is a huge huge win!

But cmdstan scripts still require it right now and I think we would need to clean up the Cmdstan makefiles, cleanup docs and installation instructions before the release. We could do that, but it feels like it would be a bit rushed to me.

And yeah, more testing time would be helpful as well. Asking Windows users to test the RC because of a somewhat big change would be helpful as well.

The only other option is making an RC2 and prolonging the freeze period.

@andrjohns
Copy link
Collaborator Author

First of all, this is awesome. Not requiring mingw32-make is a huge huge win!

But cmdstan scripts still require it right now and I think we would need to clean up the Cmdstan makefiles, cleanup docs and installation instructions before the release. We could do that, but it feels like it would be a bit rushed to me.

And yeah, more testing time would be helpful as well. Asking Windows users to test the RC because of a somewhat big change would be helpful as well.

The only other option is making an RC2 and prolonging the freeze period.

Ah yeah good point. This change isn't particularly urgent, better to play it safe

@WardBrian
Copy link
Member

Agreed @rok-cesnovar, this is a great change! I had always suspected that the issues with make and TBB were surface-level due to the makefiles rather than something fundamental, but I never had the knowledge or motivation to dig too deeply.

Getting the build system out of our way is also the current barrier to using the Microsoft compilers (or at least Clang-for-MSVC) for Stan, which is a goal of mine. One day

@wds15
Copy link
Contributor

wds15 commented Jan 11, 2024

@andrjohns I only recall that make simply did not do it and the mingw thing did it.... that's when I stopped looking for further "why". It would be great to now require any more the mingw thinggy.

@WardBrian WardBrian merged commit babb1ad into develop Jan 31, 2024
8 checks passed
@WardBrian WardBrian deleted the tbb-rtools-make branch January 31, 2024 15:29
@WardBrian
Copy link
Member

@andrjohns would you mind looking into what needs to be changed in the stan and cmdstan repos?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants